feat(components): expand staged button/card surface - #442

Walkthrough

Updates optional component CSS for .sf-btn semantic variants, token-based sizing, and width modifiers, then adds .sf-card subcomponent styling for media, avatar, title, and nested button font sizing. Token comment blocks are expanded to match the new component behavior.

Changes

Button and Card Component Enhancements

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related issues

• Components: second batch #384: This PR extends the .sf-btn and .sf-card component work with semantic button variants, sizing rules, and card subcomponent styles.

• X
• Mastodon
• Reddit
• LinkedIn

• Add semantic button variants with tokenized font sizing and consistent hover behavior.
• Introduce container-query full-width buttons with an explicit .sf-btn--auto opt-out.
• Expand smart-card subcomponents (__media, __avatar, __title) and related design tokens.

graph TD
  TOK["optional/tokens.components.css"] --> CMP["optional/components.css"] --> BTN[".sf-btn variants"] --> CQ["@container full-width"]
  CMP --> CARD[".sf-card subparts"] --> SUBS["__media/__avatar/__title"]
  TOK --> BTN
  TOK --> CARD

Loading

The following are alternative approaches to this PR:

1. Derive hover colors via `color-mix()` for all semantic variants

• ➕ Reduces the number of explicit --*-strong/--*--hover tokens needed
• ➕ Can produce smoother, more uniform hover steps across themes
• ➖ Harder to guarantee contrast/accessibility across light/dark palettes
• ➖ Less aligned with the framework’s existing direction-aware strong triplet approach

2. Use responsive `@media` breakpoints for full-width behavior

• ➕ More widely understood than container queries
• ➕ Can be driven by global design tokens more easily
• ➖ Doesn’t adapt to component embedding context (container width)
• ➖ Contradicts the PR’s intent to avoid breakpoint-driven behavior

Recommendation: Keep the PR’s approach: semantic variants map directly to existing palette tokens (including the direction-aware -strong triplet for status colors), which is more predictable across themes than computed mixes. Using container queries for the full-width rule is consistent with context-driven layout and matches the stated framework direction; the explicit .sf-btn--auto opt-out keeps the behavior controllable.

Enhancement (1) +100 / -4

components.cssAdd semantic button variants, container-query full-width, and card subcomponents +100/-4

Add semantic button variants, container-query full-width, and card subcomponents

• Extends staged '.sf-btn' with a tokenized base font-size, adds semantic variants (primary/neutral/success/warning/info) and fixes danger hover to use the '-strong' token instead of brightness filtering. Adds container-query logic to make buttons full-width under 20rem with a '.sf-btn--auto' opt-out. Expands staged '.sf-card' with '__media', '__avatar', '__title', plus a scoped nested-button font-size override via '--sf-btn-font-size'.

optional/components.css

Other (1) +15 / -0

tokens.components.cssDocument staged tokens for smart-card subcomponents and button sizing/full-width behavior +15/-0

Document staged tokens for smart-card subcomponents and button sizing/full-width behavior

• Adds documentation for new staged card subcomponent tokens (media ratio/radius, heading size, nested button font-size) and introduces a documented '--sf-btn-font-size' token. Documents the container-query-driven full-width button behavior and notes why the 20rem threshold is a literal (container query conditions cannot read 'var()').

optional/tokens.components.css

Description

.sf-btn--warning:hover switches the background to --sf-color-warning-strong but keeps text color
--sf-color-text--on-warning, even though the framework’s own auto-contrast formula (threshold 0.6)
would choose the opposite text color for the strong variant’s lower lightness. With the default
palette, warning is L=0.75 (dark text) while warning-strong is derived as L=0.50 (light text), so
hover can render with the wrong on-color.

Code

optional/components.css[R103-111]

+  .sf-btn--warning {
+    background:   var(--sf-color-warning);
+    color:        var(--sf-color-text--on-warning);
+    border-color: var(--sf-color-warning);
+  }
+  .sf-btn--warning:hover:not(:disabled, .is-disabled, .is-loading) {
+    background:   var(--sf-color-warning-strong);
+    border-color: var(--sf-color-warning-strong);
+  }

Relevance

⭐⭐⭐ High

Repo accepts on-color/contrast fixes for semantic variants (e.g., restoring correct foreground
tokens in PR #386).

PR-#386

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes .sf-btn--warning:hover to use --sf-color-warning-strong but does not change
color, so it continues using --sf-color-text--on-warning. In core tokens, warning’s default
lightness is 0.75 (dark text selected by the 0.6 threshold), while warning-strong is explicitly
derived by subtracting 0.25 lightness (≈0.50), which falls below the threshold where the same
formula would select light text—demonstrating the mismatch.

optional/components.css[103-111]
core/tokens.css[28-46]
core/tokens.css[488-495]
core/tokens.css[583-623]
core/tokens.css[1381-1399]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`.sf-btn--warning:hover` changes `background`/`border-color` to `--sf-color-warning-strong` but leaves the text color as `--sf-color-text--on-warning`. In the core token system, `--sf-color-text--on-warning` is computed from the *base* warning color (L=0.75 by default) and therefore selects dark text, while `--sf-color-warning-strong` in light theme is derived as `l - 0.25` (≈ 0.50) which would flip the auto-contrast decision to light text.

### Issue Context
- Default warning source token is `oklch(0.75 0.17 80)` (L=0.75).
- `--sf-color-warning-strong` (light mode) is computed as `oklch(from var(--sf-color-warning-source-light) calc(l - 0.25) ...)` → L≈0.50.
- Auto-contrast threshold is `--sf-contrast-threshold: 0.6`, and the on-color tokens are computed with `clamp(0.1, sign(threshold - l) * 999, 0.95)`.

### Fix Focus Areas
- optional/components.css[103-111]
- core/tokens.css[28-46]
- core/tokens.css[488-495]
- core/tokens.css[583-623]
- core/tokens.css[1381-1399]

### Suggested fix
1. Introduce a dedicated token (e.g. `--sf-color-text--on-warning-strong`) in `core/tokens.css`, computed with the same auto-contrast formula but based on `--sf-color-warning-strong`.
2. Update `.sf-btn--warning:hover` to set `color: var(--sf-color-text--on-warning-strong, var(--sf-color-text--on-warning));` so the hover state uses the correct on-color.
3. If the token is public, update `tests/token-api.snapshot.json` accordingly to keep token API tests in sync.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools